ZL1BPU FSQ Telemetry

Introduction

This page describes a series of simple products which allow you to collect data from a remote site via HF. (You could also use VHF/UHF FM, but the range would be rather limited). The site is assumed to have an FSQ station, consisting of an HF SSB transceiver and antenna, a small PC operating FSQCall V0.36, and equipped with:

• An Arduino Uno R3 micro-controller, equipped with an FSQ Telemetry Shield and appropriate Telemetry 'sketch' installed.
• A transmit 'Helper' program, which collects the data from the Arduino, formats it, and forwards it to FSQCall.

The home FSQ station would consisting of an HF SSB transceiver and antenna, a PC operating FSQCall V0.36, and:

• A receiving 'Helper' program, which then reads the received data, interprets and displays it.

Shown on the right: an Arduino Uno fitted with the WM6H FSQCall Telemetry Shield. Click on the image for a larger view.

There are probably as many ways to handle and transmit the remote data as there are hams to dream them up! Much depends on the nature of the remote site. If it has plenty of power available, a real-time transmission arrangement would be ideal. However, some remote sites have a very limited power budget, and for these an alternative file storage and daily retrieval mechanism is offered. Daily retrieval is also useful where propagation opportunities to the remote site are limited.

The 'Helper' devices are third-party computer programs designed to work with ZL2AFP FSQCall, and operate in the background. The Transmit 'Helper' generates a text file, which it places in the /Shared folder of FSQCall. Depending on the 'Helper' used, FSQCall program either finds the file (containing one formatted sentence with preamble) and transmits it within a few seconds, or (as a daily accumulation of telemetry frames) the file remains ready to be retrieved on request.

The Receiving 'Helper' can work with any of the received data files which are in the appropriate format, whether from individual transmissions collated over the course of the day, or downloaded as one daily transmission. The Receiving 'Helper' reads the requested file every 10 seconds and refreshes a graph displaying the received data on a 24-hour scale. The 'Helper' need not be run all the time, and will show all available data when run. It can be used to display data from any appropriate stored telemetry file.

Real Time Telemetry
Using the 'Helper' program FSTreal, the data is collected from the Arduino, and passed at the selected sample rate (say every 10 minutes) to FSQCall via the automatic File Send feature. At the receiving end, FSQCall operates to accumulate the transmitted data from each transmission into a common file, as defined by the remote site. This arrangement is clearly illustrated in the following diagram:

Block diagram of FSQCall 'real time' Telemetry Remote site

At the receiver, each transmission (which contains just one sentence) is stored by FSQCall in the same file, which might accumulate data for days or weeks. The user will need to manage the file by archiving it. The current file can be analysed and displayed as needed, simply by clicking on the MSG RX button in FSQCall, which will open the analysis program and display the data.

Block diagram of FSQCall Telemetry Analysis

The 'Helper' programs are third-party computer programs designed to work with ZL2AFP FSQCall, and operate in the background. The FSTreal Transmit 'Helper' generates a text file named 'data.txt', containing the appropriate preamble and one telemetry sentence, and places it in the /Shared folder of FSQCall. The FSQCall program finds it within a few seconds, and transmits it if the radio channel is clear. The Receiving 'Helper' can work with any of the received data files which are in the appropriate format. It reads the requested file every 10 seconds and refreshes a graph displaying the received data on a 24-hour scale. It need not be run all the time, and will show all available data when run.

Stored File Telemetry
This approach uses much less 'air time', so has reduced power consumption. The Arduino operates as before, but a different helper program, FSTstore is used. This saves the data to file, accessible by FSQCall, but is not transmitted automatically. Each day at midnight, a new file is started. Data files for previous days and the current day's data is available for download any time using the manual FSQCall file request. The file names are date coded. The Receiving 'Helper' can read the requested file as soon as download is complete, or used to read and analyse previous days' data.

Remote Telemetry device stores to file

The Future
Several variations to the telemetry scheme are planned, where remote devices will be equipped with their own low-powered radio transmitters, and so will be able to send the data directly, even from a site with no other FSQ equipment or PC - perhaps a holiday home, a boat, or even a free-floating ocean beacon. While the telemetry format chosen is up to the individual user, the format suggested here is compatable with the ZL1BPU software on offer. Since the system is generic in nature and well documented, and quite simple to use, anyone can write 'Helper' programs to suit their own purposes.

Arduino Device

There are course other devices which can do this job. The Arduino Uno R3 has been chosen because it is widely available, inexpensive, easy to use with excellent support and tools, and of course more than capable of doing the job.

The Arduino is connected to the remote site PC via its usual USB serial link. The data read by the Arduino board comes from a simple add-on board (in Arduino jargon, called a 'shield'), which conditions the real-world signals. This Telemetry Shield in effect defines what each channel in the transmitted data means.

FSQCall Arduino Telemetry Shield.
Click on image for larger view

The grey area shown above is the actual shield. Components to the left are part of the installation, and are indicative of how you might connect the unit up. The Arduino FSQCall Shield is arranged to provide three voltage inputs, a current input and two temperature inputs. These can be adapted to suit, and the other components of the system can be adapted accordingly. In the default setup, which is defined by the above drawing, the six channels are as follows:

AD0	Analogue Voltage 0 - 16V
AD1	Analogue Voltage 0 - 16V
AD2	Analogue Voltage 0 - 16V
AD3	Analogue Current 0 - 5A
AD4	Temperature, 0 - 50°C
AD5	Temperature, 0 - 50°C

The 0 - 16V range is achieved using a simple resistive attenuator, 220k and 100k, reducing 16V input to 5V at the micro-controller. The 5A range is achieved through reading the return current from the charger or solar panel through a 1 Ohm resistor, resulting in an input range 0 to -5V. The op-amp, which has a gain of -1, is used to invert this to 0 to +5V.

The temperature inputs use 100k (at 25°C) thermistors in series with 100k fixed resistors. By using the thermistor in the upper side of a divider, the reciprocal change in output due to variation of the upper resistor is used to compensate for the hyperbolic relationship of the thermistor with temperature. At 25°C, the resistance of the thermistor will be 100k, and the output to the micro-controller will be mid-range. Linearity is very good over the suggested range, and is less accurate beyond this range. You can also use 10k thermistors, simply by changing the matching resistor to 10k as well. Temperature measurement is ratiometric with the power supply, so the readings are independent of supply voltage.

As an alternative, LM35DZ silicon sensors (direct temperature reading 10mV/°C) can be used for temperature measurement, although the connections will change. Connect the Vcc pin to +5V, the Vdd pin to 0V, and the output pin to the temperature input in place of the thermistor.

Nothing in the Arduino firmware or transmitting software is constrained by the actual data transmitted: the design is completely generic. The data collected is defined by the Telemetry Shield used, and interpreted as so defined by the Analysis program at the receiving end.

Calibration can be completed by the Analysis (plotting) program at the receiver, which can have offset and gain values adjusted independently for each channel; or the data can be displayed raw. Alternatively, the user can write a program which converts the telemetry data into comma-separated file, for analysis using a spread sheet.

Current Sensing
There are two ways in which current can be sensed with the Telemetry Shield. If the charger and solar panel voltages do not exceed 16V, the simplest technique is to measure current by voltage difference (left or first drawing below). This is appropriate where a constant voltage charger is used. To use this method, fit a 220k/100k attenuator to the Arduino Shield current sense channel and omit the op-amp.

If this is not the case, say when using a solar controller, it is safer to measure current using a shunt in the negative return from the chargers (right or second drawing below). To use this method, the Arduino Shield must be equipped with an op-amp inverter, as the voltage sensed across the resistor is negative. This situation is the most versatile, as it allows for a lower value shunt resistor. For example if 0.1 Ohm was used, the inverter gain could be increased to -10 for the same 0 - 5A range.

The Arduino cannot directly measure negative voltages or currents. However, the data transmitted for each channel is completely generic, simply a number 0 - 4095. It is up to the Analysis program to scale and display the measurements appropriately. The FSTplot program to be described below can be set for either Voltage-difference sensed current (V), or Current-shunt sensed (I).

• V Sense - current is calculated as the difference between Vsense and Vbatt.
• I Sense - current Ibatt (-ve) is measured directly across the shunt resistor.

 
Charger Current Sensing.
Click on each image for larger view

The Arduino device sends eight channels of 12-bit data, a total frame of 24 hexadecimal characters. The first two channels are a sequence number 0 to 4095, which cycles around every hour or so, and the device ID number, either a number 0 to 4095, or a number 0 - 16, another number 0 - 256 (Group Number - set in the firmware) plus two switch sensors. A complete frame of telemetry is sent every second, with the sequence number incrementing each time. The sequence number serves to ensure that each frame is different, so the user knows the Arduino firmware has not hung up. Data is sent from the Arduino USB port at 9600,N,8,1.

The Arduino is typically powered by the USB port of the computer, which provides for a very simple installation.

Transmit Helpers

Real Time
FSTreal is a simple program which reads the data from the Arduino USB port, optionally globally scales the data (normally the scaling factor is 1), and then assembles a proper FSQCall file transfer sentence for transmission. Each file contains a single telemetry frame, formatted into an FSQCall sentence. The sentence is saved in a special file ('data.txt'), which the FSQCall program finds and transmits.

The PC Transmit 'Helper' program, FSTreal 0.04

In the above picture you can see the data displayed as each frame comes in from the Arduino (the spaces are added by the program), followed by the PC [seconds count] (this is NOT the source device Sequence Number, which is the first number in each line). When a transmission takes place (the output file 'data.txt' is saved), the FSTreal program also displays the actual complete FSQ telemetry frame transmitted (you can stretch the window to see the whole sentence). In the example you can see that the FSQ sentence is directed to zl1ee_g, for relay to zl1bpu, to be stored in the file '-t2.tlm'. The use of ' - ' in the file name tells the receiving station not to acknowledge each transmission.

zl1ee_g!zl1bpu#[-t2.tlm]2249.uqfpsvtepdcpppppppwvpwxc.

The FSTreal program uses a setup file to define the COM Port number, the number of seconds between transmissions by FSQCall, the path to the FSQCall /Shared folder, the FSQ sentence preamble and file name to save to. The setup file also sets the scaling factor and the telemetry data 'packing method'. Four methods are available:

1. Hexadecimal, expressed in lower case, packed
2. +64 shifted Hexadecimal, lower case, packed
3. Hexadecimal, expressed in lower case, space separated channels
4. Decimal values 0 - 4095, comma separated

Method 2 is preferred, since the all the data is then in lower case letters (as in the above example), so is much faster to send. It's not however 'human readable'. Method 1 is the next best, but typically takes about twice as long to send. The picture on the right shows received data in this format. The telemetry frames are delimited by special symbols before and after the data. These are used by the data analysis and display program to determine the method in use and to error check the data frame.

Before the data is sent, the time is sent as HHMM. This time is appended by the computer, using system time. Here's a typical telemetry frame, using method 2:

2002.vwvpsvtdcdccppppppwvpwxc.

The same frame sent using Method 1 would be:

2002|6760364dcdcc00000076078c|

This looks to be the same length, but it has 17 more symbols than the +64 shifted version when transmitted as FSQ, since numbers require two symbols, requiring an additional four seconds to transmit. The actual data content in the FSQ telemetry frame is as follows:

HHMM.sssddd000111222333444555.

where 'HHMM' is the time, 'sss' is the Sequence Number, 'ddd' is the digital information, switches and/or Device ID. The following data is from the six analogue channels, in order 0 to 5. All channels are expressed in Hexadecimal, MSB first. The analogue data is 12 bit, yielding a resolution on the 0 to 15V scale of four millivolts (0.004V).

The analogue channel data transmitted is completely generic, so you can design your own signal conditioning shield to read anything you like. The channel names and scaling factors are not set until they are defined by the Data Analysis 'Helper' at the receiver.

Stored File
The Stored File 'Helper' program FSTstore looks just like the FSTreal program, reads the data from the Arduino, and interprets the data in an identical manner, but there the similarity ends. Instead of making periodic 'transmissions' using FSQCall to make transmissions containing just one data frame, FSTstore instead accumulates these periodic data frames into a date-coded file. At midnight the file is closed and a new one started.

Since the files are stored in the /Shared folder of the remote computer, these files can be read over the air via FSQCall at any time, to receive either the current day's data or files from previous days. Since the files contain only the data and no preamble, the 'air time' used to send the data by this method is at least halved. A further advantage is that your home station receiver is not tied up all day waiting for the telemetry - you simply request it when you need it.

The received data looks no different, and is stored in a single date-coded file for analysis in the same way. The user can set the transmitted file name suffix (typically to an abbreviation of the remote site name or callsign), and can also set the file type (.tlm preferred). So for example, if interested in data for the date 23/08/2016, from the remote station 'BB' (callsign zl1xyz), the user should ask for the current day's file as '230816BB.tlm', using the command:

zl1xyz+[230816BB.tlm]

When the file arrives, the FSQCall MSG RX button will light, and if the file type is associated correctly, clicking on the button will open the file in the appropriate Analysis 'helper'.

Data Analysis Helpers

The receiving station FSQCall V0.36 program places the frame-by-frame data from FSTreal sequentially into the file specified by the transmitting station, which will be stored in the /Shared folder. Each subsequent data frame will be appended to the same file. An example is shown above right. Note the absence of errors - this is typical of FSQ - very low error rate.

When FSTstore is used, the file is downloaded in one transmission to the /Shared folder, but looks otherwise identical.

The analysis software weeds out dud frames and invalid time stamps, but does not sanity check the data. If you look closely at the picture below, you'll see there are no obvious data outliers, only the occasional missing data frame, but they don't detract from the usefulness of the result. An independent analysis of 140 telemetry frames, sent over a 14 hour period, showed four character errors in 4200 sent, or 0.02% errors. Most of these transmissions were relayed over two 300km paths.

FSTplot data-specific Analysis program.
Click on image for larger view

Two Data Analysis 'Helpers' are offered (of course you can write your own). FSTplot has specific requirements of each data channel (outlined above), and has a setup file which tells it which file to analyse, and also defines the names for each data channel, their scaling factors and offsets. The program will handle both current sense and voltage difference current measurement methods, but is tied to the specific use of each channel. However, the data is displayed directly in Volts, Amps and °C (see picture above).

As you can see in the above diagram, FSTplot has a large white graph at the top (about 260 pixels high), and various text information at the bottom. The graph has three Y axes offered, depending on the sensors and scaling used: 0 - 16V, 0 - 5V or 5A, and 5 to 45°C. These are fixed, not preset, and the data is scaled to fit the calibration. Use whichever scale is appropriate for the data. The horizontal axis is time, 0 - 24 hours, with a resolution of 2.5 minutes. The data frames are plotted against the timestamp sent at the start of each frame, which was appended by the transmitting station. In theory you could plot on the same graph for days on end, but it is best to close the FSTplot program, say first thing in the morning, rename and archive the data, and then after the next data sentence has arrived, restart FSTplot.

Below the graph is a legend, colour coded to the data displayed in the graph. Beside the name of each channel is a coloured dot (to the left) and to the right the most recent reading for each channel, again colour coded. The name of the file currently displayed is also shown here.

At the far right (in grey) are the most recent Sequence Number, the Device ID that is being displayed, the status of the two switches (usually zero) and the time stamp of the most recent valid telemetry frame.

At the very bottom are two lines, showing the raw (encoded) and Hex (decoded) data from the most recently received frame, and may show errors from time to time.

Looking closely again at the graph in the above picture, you can see that there are fewer 'spots' in some places, indicating a reduction in the rate of reception of viable telemetry frames. For the most part this is because the telemetry is sent on an active channel, and when other stations use the channel, the low priority telemetry times out and is not sent. This effect can also happen when transient noise occurs on the radio channel. The general trend of the data is not lost. As a rule of thumb, send the telemetry about twice as often as you think you'll need it.

FSTraw ( see below) looks similar, but has no specific requirements on the data channels, as it displays all six channels on a fixed scale 0 - 4095 (or 000 to FFF hex). So it will be appropriate no matter how you decide to deploy the channels. FSTraw has the added advantage that, if associated with file type '.tlm', the program will open, interpret and display any .tlm file when you double-click on it.

FSTraw generic Analysis program.
Click on image for larger view

In this picture, it is analysing the same data as in the earlier FSTplot image. You can still measure any of the parameters, since each channel has the current value shown (0 to 4095) next to the Legend. But you will need to know the scaling factor (say x16/4096 for a 16V range) and keep a calculator handy.

There are two other minor differences with FSTraw. The name of the file being analysed is shown on the banner (very top of the window). The user can optionally (for each individual channel) display a magnified (x16) view of the data, which is a useful way to see minor variations. The magnified data is shown colour coded, but just as tiny dots. In the picture above, the Ambient Temperature (blue) and Battery Voltage (Red) have this magnified feature turned on. This feature illustrates just how much data resolution is available from the Arduino in 12 bits. Yes, 0.025%!

Installation

This procedure assumes you have two PCs and SSB radios, one at a remote site, operating FSQCall using battery power; the other a conventional home station used to monitor the remote site. VHF/UHF or 10m FM also works well, but the range will be reduced.

Remote Site
First, program the Arduino Uno R3 using the sketch provided. Build up and test the Telemetry Shield. (Bob WM6H is offering inexpensive PCBs - but Veroboard works well too). You can test the arrangement by monitoring the returned data using the Arduino IDE serial monitor. You'll need a Hex calculator to work out what is being sent.

Once the FSQCall station is fully operational, and the Arduino assembled and tested, connect up the sensors to the battery supply and the radio, using the pictures on this page as a guide. It might pay to print them out.

Install the Arduino IDE on the remote site computer so the Uno driver gets installed. (I don't know of a way to install the genuine driver without installing the whole IDE). Clearly it's best to install and test everything before heading to the remote site!

Connect the Arduino via its USB cable to the PC, and make sure that the Arduino USB driver loads correctly. Check Windows Device Manager to discover which serial port the Arduino resides on, and write this value down. You can check that you are receiving data by connecting to that port using a terminal program, such as puTTY, or the Arduino IDE serial monitor. If a PC application is receiving the data, you'll see the yellow serial comms LED on the Arduino flash once/second. If the data backs up because no program is receiving, the light will soon stop flashing.

Install the PC software supplied, by unzipping the archive into a new folder, ideally a sub-folder to the FSQCall installation.

Real-Time
For real-time use, edit the file FST.set so that it has the correct COM Port number (the one you wrote down), the required transmission rate in seconds, and set the path from where the FSTreal004 program resides to where the FSQ Shared folder is, and name the output file as "data.txt". This might for example be "../Shared/Data.txt". By the way, you can successfully direct the file to a /Shared folder on a different computer on a network. You'll see this in the FST.set file supplied ("\\LENOVOM58\Shared\Data.txt"). For this trick to work, you must have the host computer visible and shared on the network, and the Shared folder shared for read/write.

Also in the FST.set file, define the precise FSQ preamble the file will need. It must contain a target callsign, the "#" file store command and the name of the file to store the data frames in, for example "zl1bpu#[dev036.tlm]". The telemetry data will be appended to this preamble each time it is transmitted. Don't make the preamble any longer than necessary, as it can take longer to send than the data!

Finally, select the packing method, the last item in the FST.set file. Method 2 is recommended, as it's the fastest to transmit. Save the file, then start FST004.exe. If all is well (no errors in the setup file, the Arduino is running and the COM port is behaving), the small FST004 window will appear, and you'll see the data flowing by.

Very soon FST will save a sentence as 'data.txt'. If it is correctly saved in /Shared, FSQCall will pick it up and transmit it. If the message appears in the TX buffer, but is not transmitted, and soon disappears, check that the channel is clear, and that the FSQCall squelch is set appropriately. If the message is sent, you're in business!

Note: You can increase the time FSQCall waits for a clear channel by increasing the 'Options/TX reply retries' value. A value of 20 would be appropriate.

Hint: If FST004 (the program that receives telemetry from the Arduino) plays up, it will probably be due to RF getting into the USB port. The error messages here are less than useless! Reboot the computer and run FST again without FSQCall running. On some computers you may be able to disable and re-enable the COM port via the Device Manager, which is a lot quicker then rebooting. Does it work OK now? If so, reduce the transmitter power before restarting FSQCall, or find some way to keep the RF out. Using a decent dipole antenna well away from the computer will help.

Stored File
Edit the file FSTstore.set in the same manner as described for real-time operation. Set the COM port, the data rate (in this case the storage rate, not transmission rate), where to place the file, and the file suffix. The date will be prepended to this to name each day's stored file. Finally, as before set the scaling factor (best left at 1) and the data packing method (2 is preferred).

Once the file has been saved, start FSTstore000.exe. Very soon the first sentence will be saved to the day';s file, and others will be appended in due course. Users will now be able to request the data via FSQCall using the ' + ' file transfer command. The Hint above about FST004 playing up also applies to FSTstore000. Some USB ports seem to be prone to RF interference.

Receiving Site
As a minimum, unzip the files FSTplot001.exe, FSTplot.set, FSTraw000.exe and FSTraw.set into the FSQCall working folder. Ideally also unzip FSTHelp.htm and associated images. If you plan to use the suggested Arduino Telemetry Shield and the same channel definitions, you can use FSTplot. Edit FSTplot.set to define your own setup. You can always change it later. Specify the exact path to the Shared folder from where the program resides. Specify the name of the telemetry file you are receiving (at some time later you could specify a static archived file). Set (if necessary) the names, scaling factors, current sense method and offsets for your installation. If the remote site is set up as suggested, the values supplied in the file should be suitable.

If you use a different arrangement for the Arduino Shield, you should either write your own analysis program, or use the generic program FSTraw000.exe. Here the setup is simpler. You can tell the program to display only data from one device, or drom all devices. While you can label the channels with names, they can't be scaled or offset. You can set the magnified view on for each channel individually (but it's not wise to do that for more than two channels at a time). There's no file name to set, as FSTraw displays when you double-click on a file.

To set the file association in windows, right-click on a .tlm file, select 'Open with', and 'Choose default program...'. Then use Browse to navigate to FSTraw000.exe, select it and click OK. This method does not work with FSTplot, which is intended for use mostly with a single file.

Run FSTplot001.exe or FSTraw000.exe (in the latter case by double-clicking a .tlm file), and it will display the whole contents of the received telemetry file, for the specified Device, and will continue to refresh as more data arrives. If no data displays, check the Device number in the appropriate setup file (should be the decimal equivalent of the second field in the received data, or set to ALL for FSTraw).

If the program generates an error message, you will have either specified the wrong path or file name, or you have not preserved the correct order of information in the setup file. Or you might simply have not received any data yet! Check the Monitor. The red MSG RX light should be on if telemetry reception is active.

Other applications

Multiple Sites
It is possible to receive real-time telemetry at multiple sites. All that you need to do is set the remote site FSQ preamble to "allcall". Provided the telemetry sent includes a ' - ' in the target file name, you can also receive telemetry intended for other folk simply by setting the FSQCall station callsign to that of the target station. This provides a convenient way to check what's happening when away from home. If the file name didn't include ' - ', you would need to disable the transmitter to prevent inadvertent 'ack' transmissions with an inappropriate call sign.

Multiple Devices
It is also possible to have multiple devices sending telemetry to the same station, or to all stations, and even to the same target file! For this reason it is important that different Device Numbers are set in each remote device. If this is not the case, they should send to different files. FSTplot only plots data for one Device number at a time. In order to plot from two or more devices at a time, install multiple instances of FSTplot in separate folders, and edit the individual setup file Device numbers accordingly.

Data Bits
FSTPlot handles the 12 data bits in the following way: the lower four bits (of the 12) are treated as the Device number, 0 - 15.

The next two bits represent two switches on the remote device. These could be a tamper alarm, mains power lost, an over-temp alarm or whatever. The normal state is zero, switch closed. If these two bits are zero, plotting continues normally. If either or both is 1 (switch open, since the Arduino has internal pull-ups on these inputs), the FSTplot program places a dark blue dot below the zero line at that the corresponding time stamp. The current state of these two switches (0 - 3) can be read from the grey text at the right of the FSTplot window.

The switch bits are not part of the Device number, although they are transmitted in the same channel. The upper two bits of the middle nibble of the data bits are ignored, as are the left-most (MSB) four bits. The plan is for these six bits (which are not read from inputs) to be hard-coded Device Group numbers. allowing users to have 64 groups of 16 Device numbers. A later application could screen for Groups as well as Device numbers.

Write Your OWn
FSTPlot is fairly simplistic and makes quite a few assumptions about what the remote connections are, and what the Telemetry data contains. If it's not suitable for your purpose, feel free to write your own. The telemetry format is well defined (and of course you could change that too). The Analysis program has no direct interaction with FSQCall: it simply reads incoming Telemetry files.

Other Helper Software

Anyone can write software to interact with FSQCall V0.36 or later. There are several output products that can be utilized by third-party software, and one input mechanism:

1. Heard Log
   The Heard Station Log file Heardlog.txt can be read and analysed. It contains call sign, date, time, "snr=", SNR, and "dB". Each line of the file represents one 'spot' (detected valid FSQ sentence). The entries are comma separated. The ZL1BPU application FSQPlot already makes use of this data to display a graph of signal quality of six designated stations over 24 hours.

2. Incoming Message Files
   Any or all of the files in the Shared folder can be accessed by other applications. These files typically represent incoming message files or data. These may include formal messages, formatted messages, and simple text or data. The file suffix .tlm is reserved for incoming telemetry data. Other applications may also delete, rename, create or edit files in this folder. These files are accessable by other FSQCall users. FSTplot by ZL1BPU plots data from designated remote devices over 24 hours.

3. Images
   The images in the Shared/Images folder can be accessed by other applications. Other applications may also delete, rename, create or edit files in this folder. These images are available to other FSQCall users.

4. Sending Files
   A third-party program can also create a specific file, 'data.txt' in the Shared folder, and within five seconds FSQCall will find and read the file, transfer the complete text content to the transmit buffer, delete the file, then (if the channel is clear) transmit the text.

   This mechanism can be used for transmitting telemetry or any 'Smart Sounding' messages generated by a third-party program. Both of these applications have already been demonstrated. Of course the file needs to contain a correctly formatted FSQCall sentence, or it won't be recognised at the intended destination. This technique is generally used with the ' # ' (File Send) command, but any valid command is permissable. Without a valid preamble, the file will be sent as a Sounding, and only appear in the Monitor and Heard List (not log) at other stations. It will not be stored as a file.

The use of file sending by a third-party, combined with file receive by a third-party is a very powerful technique. Although it has not been tested as yet, the technique would allow third-party Formatted Message and Error Correction programs to send and receive error coded files, and even if necessary to operate an ARQ protocol.